ベストプラクティスを知ろう (2) #サービスマネジメント
prismatix事業部 の菊地です。
みなさま、日々の運用、お疲れさまです。
前回は「ベストプラクティスを知ろう」と題して、 ITIL とそのフレームワークについてご紹介しました。
今回は「ITIL 4」の第二弾として、主に「Ops」に関連する管理プラクティスのうち、サービスプロバイダがあらかじめ用意すべき、以下の管理プラクティスについてご紹介したいと思います。
- サービスデスク
- サービスカタログ管理
- サービス構成管理
- サービス要求管理
- 変更管理
ITIL 4 管理プラクティス
まずはじめに、前回のおさらいとして ITIL 4 で管理されるプラクティスについて種類毎にご紹介します。
| 一般的マネジメントプラクティス | サービスマネジメントプラクティス | 技術的マネジメントプラクティス |
|---|---|---|
| アーキテクチャ管理 継続的改善 情報セキュリティ管理 ナレッジ管理 測定および報告 組織変更の管理 ポートフォリオ管理 プロジェクト管理 関係管理 リスク管理 サービス財務管理 戦略管理 サプライヤ管理 |
要員およびタレント管理 可用性管理 事業分析 キャパシティおよびパフォーマンス管理 変更管理 インシデント管理 IT 資産管理 モニタリングおよびイベント管理 問題管理 リリース管理 サービスカタログ管理 サービス構成管理 サービス継続性管理 サービスデザイン サービスデスク サービスレベル管理 サービス要求管理 |
サービスの妥当性確認およびテスト 展開管理 インフラストラクチャおよびプラットフォーム管理 ソフトウェア開発および管理 |
ITIL 4 ではこれらのプラクティスを管理することで、サービス全体を適切に管理していくことを目指していますが、次に「Ops」に関連する主要な管理プラクティスについて、より具体的な内容を見ていきたいと思います。
なお今回の記事では JIPDEC ([一財]日本情報経済社会推進協会) が公開している「ITSMSユーザーズガイド」を参考にしています。詳細につきましては以下ガイドをご確認ください。
ITSMSユーザーズガイド-JIS Q 20000-1:2020 (ISO/IEC 20000-1:2018)対応- https://www.jipdec.or.jp/archives/publications/JIP-ITSMS111-30.pdf
サービスデスク
サービスデスクとは、ユーザからの問い合わせやサービス要求、またはインシデント報告などを受け付けるためにサービス・プロバイダが用意すべき窓口機能のことで、それはすべてのユーザに対して用意され、また単一の窓口(スポック[SPOC]、Single Point Of Contact の略)であることが望ましいとされています。
サービスデスク・プラクティスは、実際にサービスデスクを開設し、ユーザからの各種コンタクトを受け付け、それらを確認、分類、および対応をしていくことを目的としています。
なおサービスデスクを開設にあたり、以前のように物理的なコールセンターを構築するのみならず、現代では仮想的なチームの編成や、チャットボットなど IT 技術の活用も進んでいます。
ただし他のチームとも密接に連携しながら、サービスデスクがハブとなって顧客に対して価値を提供するといった基本的な機能は変わらず、他方で顧客体験(CX、 Customer eXperience の略)が重要視される現代においてはその重要度が増しているとも言えます。
サービスカタログ管理
サービスカタログとは、サービスプロバイダがユーザに提供するサービスについて明文化した情報のことで、必要とするユーザや利害関係者に対してサービスカタログへのアクセスを提供します。
サービスカタログには、提供するサービスそのものや、関連するサービス要求などに関する具体的な説明、およびサービス間の依存関係などに関する情報などが含まれている必要があります。
サービスカタログ管理プラクティスは、サービスカタログを作成し、編集および最新の状態を維持し、ならびにユーザや利害関係者に対してアクセスを提供することを目的としています。
サービスカタログへのアクセスを提供するすることで、ユーザや利害関係者に対してサービスの内容を正しく伝えることができ、他方でユーザや利害関係者からのサービスに対する期待値を適切に管理する(過大な期待を持たせない)効果も期待されます。
サービス構成管理
構成管理とは、サービスの構成品目 (CI、Configuration Item の略) について、構成管理データベース (CMDB) を構築した上で格納することで、サービスライフサイクルにおいて構成情報を適切に管理することを指します。
構成管理プラクティスでは、構成情報を適切な詳細度のレベルで管理することで、変更管理、インシデント管理、問題管理、リリースおよび展開管理など関連プラクティスと連携することで、サービスを効果的に管理することを目指します。
なお、管理する CI の属性情報が多すぎる・詳細すぎると、管理工数やコストが大きくなりますので、その CI にとって本当に必要な情報のみを管理対象とすることが望ましいと言えます。
構成品目 (CI)
構成品目 (CI) の例をいくつか紹介します。
- サービス自体
- 構成コンポーネント
- 文書 (手順書、仕様書、契約書)
- その他
構成管理の活動
構成管理の各活動は以下の通りとなります。
- 管理と計画立案
- 構成識別
- 構成コントロール
- ステータスの説明及び報告
- 検証
サービス要求管理
サービス要求とは、ユーザからの問い合わせや、事前に定義された簡単なリクエストなど、発生頻度が高くかつ低リスクかつ低コストである、標準化された要求のことを指します。
サービス要求管理・プラクティスは、サービス要求を記録/分類し、優先度付けをした上で、あらかじめ整備された標準的なマニュアルに基づき対応することで、合意した SLA 内で確実に処理することを目的としています。
またこのようなサービス要求に関する独立したプラクティスをもつことで、インシデント管理や変更管理など時間を割いて慎重に対応すべき他のプラクティスに対して、チームが持つ時間や能力を集中的に割り当てることができるようになります。
なおサービス要求の中には開始から終了まで自動化出来るものもあり、これをセルフサービスとして実現することについても検討が必要です。
変更管理
変更とは、サービスに直接的または間接的な影響を及ぼす可能性がある、何らかの追加、修正、削除などのことです。
変更管理とは、変更を効率的かつ迅速に行うために標準化されたプラクティスを確立しながら、変更を実施するにあたってのリスクを最小限にとどめるための効果的な取り組みのことを指します。
サービスへの変更は様々な要因により発生しますが、変更を行った後にインシデントが発生する場合が多いことも事実です。そこで変更管理がそれら全ての変更を管理することで、変更により発生するインシデントを抑えることを目指します。
変更実現プラクティスは、変更のリスクについて評価を行い、その上で適切な権限者により実施が承認され、変更自体を管理することで、変更が成功する確立を高めることを目的としています。
変更の種類
変更には、標準的な変更、通常の変更、緊急の変更の３種類があり、それぞれ異なる方法で管理します。
a. 標準的な変更
マニュアルが用意され、リスクが軽減されており、あらかじめ承認されている変更です。変更の実施にあたり都度承認を得る必要はありません。標準的な変更のパターンを多数用意していくことで、効率的かつ確実な変更を行うことが可能となります。
b. 通常の変更
通常のプラクティスに従って計画、リスクの評価、承認を行う必要がある変更です。変更におけるリスクについて評価を行い、その上で変更許可の権限者（変更諮問委員会や変更許可委員など）により実施が承認され、変更を管理する必要があります。
c. 緊急の変更
早急に対応しなくてはならない変更のことで、可能な限り迅速に対応します。例えばインシデントやセキュリティ脆弱性への対応などがこれに該当します。迅速に対応できるように、リスクの評価や承認などが素早く処理されます。緊急変更が発生するとその他の作業が中断してしまう可能性があるため、緊急変更はサービス・プロバイダとユーザとの間で定義、文書化、合意しておく必要があります。これは緊急変更が乱用・悪用されることを避けるためです。
変更管理フローと活動
変更管理フローは以下の通りとなります。
出典： [一財]日本情報経済社会推進協会「ITSMSユーザーズガイド」
また変更管理の各活動は以下の通りとなります。
1. 変更要求の記録と分類
受け付けた変更要求を全て記録します。記録する項目（必須項目、オプション）については、事前に決定しておきます。
2. 変更要求の評価（アセスメント）
変更要求は、リスク、サービスへの影響、財務への影響、事業利益、技術的実現性などを考慮して、開発や構築の前に評価します。この評価では、ビジネスと技術のそれぞれの観点から評価を行います。
3. 変更の承認
変更許可の権限者（変更諮問委員会や変更許可委員など）が承認するかを決定します。承認された変更は全てスケジュール化され、関係者が参照出来るようにします。
4. 変更実施の調整
変更管理は、変更の実施を行うのではなく、変更をコントロールし、スケジュール通りに実施されるよう、監視・調整・コントロールします。
5. 変更のレビュー
変更結果の有効性についてレビューします。全ての変更は一定期間ごとに分析され、変更量の増加状況、頻繁に再発する変更の種類、傾向などを確認します。レビューにより導き出された結論は記録され、改善活動計画に反映されます。
標準化により生じる好循環
上記でいくつかの管理プラクティスについてご紹介しましたが、あらかじめ「サービスカタログ」を定め、また「サービス要求管理」や「変更管理」で標準化が必要であるというお話をさせていただきました。
基本的には、サービスである以上、いつ誰が対応したとしても、同じ品質で同じサービスが提供されることを目指していくというスタンスに変わりはありません。
一方で標準化にあたり、そもそも標準化すること自体に工数が発生したり、また標準化されたマニュアルには無駄な手間が生じてしまうのではないか、といった懸念もあるかと思います。確かに経験豊富なエンジニアが、その能力を最大限発揮して最短経路で実施するステップに比べると、標準化された汎用的なステップでは多少なりとも余計なステップを踏まなければならない可能性があります。
しかしながら標準化について考える際、「コンテナを活用した海上輸送の革新」という歴史的な事例について思い出します。
かつて貨物船の荷役は、大勢の港湾労働者によって荷物ごとにそれぞれ手作業で行われていましたが、荷物の積み下ろしには長い時間を要し、その結果として沖合では多数の貨物船が着岸出来ずに待機を強いられ、それらの結果として海上輸送には膨大な時間を要し、またかかる費用も高額なものとなっていました。
そんな中で「コンテナ」や「コンテナ船」、「ガントリークレーン」が開発され、海上輸送のコンテナ化によってかかる時間も費用も大きく削減され、その結果として貿易や物流の形が大きく様変わりしました。またシェア拡大に伴ってさらなる改善を引き起こし、今やコンテナによる海上輸送がグローバルサプライチェーンに欠かせないものとなっていることは、みなさんご承知のことかと思います。
確かに実際の「コンテナ」１つ１つをとった場合、上部に無駄な空きスペースなどが生じてしまうかもしれませんが、標準化を図ることでハードも共通化し、プロセスも単純化され、シェアの拡大によりさらなる好循環を引き起こし、それら結果の積み重ねによって多大なる効果を生み出す、というよい事例ではないかと思います。
なお海上輸送のコンテナ化によって、大勢の港湾労働者が職を失う結果も引き起こしましたが、その点はご安心ください。サービスマネジメントにおいてエンジニアが活躍すべきフィールドは広大であり、インシデント管理や変更管理、問題管理や継続的改善など、本来その能力を割くべきであったプラクティスに専念することで、より一層の好循環を産む土壌が育まれていきます。
次回の予告
このブログでは、実例を織り交ぜながらサブスク / DX 時代に求められる「Ops」のあり方について、複数回にわたって考えていきたいと思います。
今回は「ITIL 4」の第二弾として、主に「Ops」に関連する管理プラクティスのうち、サービスプロバイダがあらかじめ用意すべき、以下の管理プラクティスについてご紹介しました。
次回は「ITIL 4」の第三弾として、主に「Ops」に関連する管理プラクティスのうち、インシデントや問題、継続的改善など、発生した課題の解決に必要となる、管理プラクティスについてご紹介します。
仲間を募集しています！
prismatix事業部では、お客様により良いサービスを提供し続けるために、一緒にお仕事をしていただける仲間を募集しています。
クラウドインフラエンジニアを募集しています！
現在、自社サービス 「prismatix」の事業拡大に伴い、インフラ運用・改善をご担当いただく以下２ポジションについて募集しています（ 2022/12 現在）。
それ以外の現在募集中のポジションについては下記のページからご確認ください。
もし気になるポジションがありましたらお気軽にお問い合わせください。
